D Plus第八期AMA回顾—ICLighthouse为IC DeFi带来哪些解决方案
文章来自于｜D Plus
投稿、转载请联系｜D Plus小助手
对于多数L1区块链，都面临着去中心化、安全性和可扩展性之间的最终权衡，而此问题的潜在解决方案是基础层分片，以及各种L2解决方案（包括状态通道、ZK等）。然而，在许多情况下，可扩展性的努力却削弱了DeFi最突出的两个特性：可组合性和一般事物原子性。拥有无限可扩展性的IC网络也同样面临事务原子性问题，多数情况下，一笔交易会涉及多个跨合约/容器（多个await调用）调用，这导致DeFi开发者们需要在数据最终一致性上抽出更多的精力开发。
ICTC（IC事务协调器）是一个用于在IC网络上DeFi应用开发的分布式事务框架，主要是改善在IC网络上Motoko开发的原子性问题，我们很高兴邀请到了William/ ICLighthouse创始人和Avida/ ICLighthouse核心开发者参加D Plus的第八期AMA活动 “ICLighthouse为IC DeFi带来哪些解决方案”
关于ICTC的产品更新可关注ICLighthouse的推特：👇
https://twitter.com/ICLighthouse
ICTC Github：👇
https://github.com/iclighthouse/ICTC
DRC20 Token标准：👇
https://github.com/iclighthouse/DRC_standards
Susy：大家好，我是本次AMA 的主持人Susy，一个正在深耕Dfinity生态，并不断成长的KOL。欢迎大家关注我的推特@susyspace1，与大家共同分享生态中那些有趣的事～
Susy：今天邀请到的AMA嘉宾是ICLighthouse的William/ICLighthouse创始人和Avida/ICLighthouse核心开发者，ICLighthouse 是一个建立在IC网络上的DeFi基础设施项目，也是本次“2022 IC训练营”中的入营项目之一，欢迎William和Avida！
William：大家好！我是ICLighthouse的William，我之前跟我们团队是在ETH上做DeFi领域的项目，然后在2020年开始关注IC生态，到2021年下旬开始正式转到这边来。今天很高兴能和大家分享我们的项目成果，同时也感谢D Plus的精心组织。
Q1：Motoko的原子性问题和ETH的对比？
William：ETH是天生支持原子性的，要么全部成功，要么全部失败。但同时他是放弃了性能。而IC网络是提高了性能放弃了原子性。在IC网络上的一次交易中，智能合约处理多个跨容器调用（多个await调用），需要实现数据最终一致性。
Susy：那么也就是说IC虽然拥有超强的性能，但在原子性开发上还有需要完善的地方，可以这么理解吗？
William：是的，但也不能说到底谁更好，只是IC给了大家另一种可能性。
Q2：介绍一下ICTC分布式框架？
William：IC事务协调器（ICTC）是一个用于IC网络上Defi应用开发的分布式事务框架。ICTC主要是改善在IC网络上Motoko开发的原子性问题，帮助开发者更快速的开发应用而不需要在应对原子性问题上耗费大量精力。
Susy：很棒啊~ICTC可以在很多方面可以减轻开发者的精力。
William：是的， 这会大大减少开发者的工作量，其实原子性问题是可以通过开发者的逻辑自行解决，但是要耗费大量时间和精力，甚至要远远多于自身的业务代码，所以我们构建的这套框架可以降低开发门槛以及提升开发效率。
Q3：ICTC支持Saga和2PC协议吗？
William：目前版本支持Saga协议，后面会支持2PC协议。
Q4：ICTC是怎么工作的？
William：ICTC主要是由3部分组成的，事务管理器（Transaction Manager，TM），任务执行器（Task Actuator，TA）和事务补偿器（Transaction Compensator，TC）。事务管理器主要负责对事务的状态进行处理，开发者首先创建一个事务订单order并声明补偿机制，然后创建需要执行的任务task中，最后交给任务执行器执行。在任务执行的过程中，如果发生异常需要回滚，任务管理器会根据创建时声明的补偿机制进行回滚或者阻塞，等待治理补偿。
另外事务中的每个任务都要求原子性的，即任务失败相当于该任务没执行过。因此在使用ICTC时需要具备分布式和异步调用编程思维。
Q5：ICTC有几种工作模式？针对什么场景？
Willaim：目前有2种工作模式
1、Forward模式：假设一定能成功，如果出现异常，通过治理向前补偿直到成功。这种模式主要针对无法回滚的应用场景。比如已经向某个account发送了一笔交易，此时是不能够在从对方账户中扣除回来我们的交易金额。因为假设了调用一定能完成，调用方的状态变量可以在调用时就立即保存。有些状态数值需要调用结束后才能确定的，可以在Callback中处理。
2、Backward模式：假设事务失败能有效回滚。
Q6：ICTC的补偿机制是什么？
William：对于处于Blocking状态的事务订单，可以使用任务补偿器进行补偿操作。补偿操作主要有3个接口：remove()用来移除未完成的任务，append()用来添加新的补偿任务，complete()用来执行补偿任务。
Q7：DRC20是一个什么样的Token标准？
William：DRC20是一个用于Dfinity Token的标准接口。该标准符合ERC20的接口规范，并有一些改进以符合IC网络的特点。比如支持原子性，支持ICP的账户体系，支持消息通知等。
Q8：DRC20 Token标准支持什么账户体系？
William：ICP使用的是AccountId账户体系，一个Principal可以通过子账户生成多个AccountId，可以保护隐私。现在IC上很多的NFT、Token使用Principal账户体系，缺点是无法使用子账户、无法保护隐私。DRC20内部使用AccountId账户体系，支持子账户，并兼容Principal账户体系，接口使用Address（Text）格式，能自动识别AccountId和Principal。
Q9：DRC20标准如何实现通知功能？
William：Dfinity没有现成的事件通知机制，通常做法是容器保存消息，然后应用主动去查询。在有些场景下，应用Canister需要使用pub/sub模型来订阅Token Canister的消息并执行回调函数。因此，DRC20增加了subscribe()方法，并且订阅者需要实现回调函数。如果订阅者未能收到消息或未成功处理消息时，可以使用txnQuery()查询历史记录作为补充。
Q10：DRC20标准如何更好地帮助开发者解决原子性问题？
William：首先DRC20的每个方法本身都是原子性的。同时也提供了lockTransfer()和executeTransfer()来满足开发者对原子性的需求。比如对2PC模式的支持。而且lockTransfer/executeTransfer跟approve/transferFrom的主要差别在于，即使approve()之后，transferFrom()仍然有可能失败（比如对方余额不足的情况）。而lockTransfer()会事先锁定余额，而且有过期时间，如果发生异常会自动退回。
Q11：DRC20标准能否兼容其他Token标准？
William：可以兼容，我们采用了兼容性token标准命名空间的方式。这种方式的约定是：主接口使用ERC2的方法名称实现标准方案。可选的兼容性接口使用方法名称加上命名空间（前缀xxx_）实现自我/其他标准方案。目前DRC20的主接口实现的是DIP20标准，所以可以和DIP20标准进行兼容，并且跟plug有很好的集成。
社区提问Q1：ichouse区块浏览器今后可以替换icrocks吗？
William：我们的区块链浏览器是http://ic.house，未来功能会不断完善，我们希望ICTC和DRC20能成为ic上defi开发者的好工具，为社区贡献一份力量
社区提问Q2：兼容其他token标准是比如说将ERC20 token跨链到ICL上吗？
William：不是跨链或者跨容器，是一个token的接口同时实现了两套接口。关于BTC和ETH桥链到IC网络的问题，我们也正在关注。
社区提问Q3：DRC20和SNS的Ledger Canister的Token标准采用的账户体系都是Account的话，那么是否可以实现兼容呢？
William：可以兼容，我们的目的就是为了和ICP的账户一致。
社区提问Q4：前面提到的先查询余额再扣费的例子中，很可能出现真正扣费时，发现余额不足的情况， 如何更好的去避免这种问题？
William：这个问题非常好。这种情况技术是无法解决的，所以只能做好第二笔转账交易失败时的处理方案，这也是ic开发的难点，业务逻辑要多很多，分布式编程都有这个问题。
社区提问Q5：ICLighthouse解决原子性问题的代码和设计，能否抽象成一个开源库，共享给所有的ic开发者？
William：ICTC会开源的，这个项目也是拿到了官方的grant，所以会开放给大家使用，目前开发还没完成，但已经在内部项目实践。
历史AMA回顾
联系我们
t.me/DFINITY_ZH
twitter.com/D_PlusCommunity
twitter.com/D_PlusCN